Description

The PR removes the use of the Gitpod User Environment Variable GCP_ADC_FILE in favour of a much more tightly scoped service account key which is controlled as a Gitpod Project Environment Variable PREVIEW_ENV_DEV_SA_KEY.

PREVIEW_ENV_DEV_SA_KEY is configured centrally which means that it's much easier for us to rotate. The service account has a limited set of roles assigned and only has access to the gitpod-core-dev GCP project which means that the blast radius is much smaller if it is ever leaked. For more information about this see our internal RFC Removing GCP_ADC_FILE.

By using a Project Environment variable we get the benefit that it will be accessible during prebuild execution. This means that when we build previewctl it will be able to use the remote leeway cache rather than build it every time. Unfortunately there's a bug in Leeway that means we don't populate the cache at the moment, so we don't see this improvement yet: gitpod-io/leeway#137 ➡️ Writing the service account key to disk means it would be part of the prebuild - and while it was in /home/gitpod/.config which isn't part of prebuilds today (only files in /workspace are) that might change in the future, so to be safe we no longer use the key during prebuilds.

Using this service account also eliminate the current manual step of gcloud auth login --no-launch-browser which was needed to get access to the leeway caches - this means that leeway run dev:prevew will no longer require that you sign in to GCP.

Related Issue(s)

Part of https://github.com/gitpod-io/security/issues/79
Fixes #13714

How to test

Test that dev:preview still works

leeway run dev:preview

Test that the Werft job still works

werft job run github -a with-preview=true

Release Notes

NONE

Documentation

N/A

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh